数据中台是什么，不是什么，就这么拨乱反正吧 by 傅一平

Original 傅一平与数据同行 2022-05-08

收录于合集 #数据中台 3个

现在讲数据中台跟数据仓库、数据湖、数据平台等区别的文章很多了，新人与老人看了这些文章后，对于数据中台的态度往往是不一样的。

数据新手更愿意接受数据中台这个新概念，但由于缺乏实践，往往抓不住本质，特别容易将其与其他概念混淆，然后领导问到底是什么区别的时候，支支吾吾答不上来。

数据仓库老手接触到数据中台这个概念的时候，更习惯于跟原有认知体系比较，然后抓住一些本质相同的东西，甩出一句：“换个名字而已”的观点，从而丧失了学习新东西的机会。

自己看了很多讲数据中台区别的文章，也写过一些文章，总体感觉是抓不到最本质的东西，大家似乎都在找相关关系，但因果关系难找，因为阿里在提出数据中台的时候，给出的是一个泛泛的定义，比如以下这种：

“数据中台是指通过企业内外部多源异构的数据采集、治理、建模、分析，应用，使数据对内优化管理提高业务，对外可以数据合作价值释放，成为企业数据资产管理中枢。数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。数据中台建立后，会形成数据API，为企业和客户提供高效各种数据服务。”

没有比较就没鉴别，其实数据仓库也完全可以这么定义，我们必须要找到一种直戳本质的定义，你只要通过这种定义去判断，就可以把数据中台跟数据仓库，数据湖，数据平台等区分开来。

我这里尝试给出数据中台的一个定义，即数据中台是支持多个前台业务且具备业务属性的共性数据能力体系，其包括了四方面的特征：

（1）数据中台必须直接支撑前端业务

（2）数据中台提供的数据能力可以复用共享

（3）数据中台的数据模型构建以业务为核心

（4）数据中台是个体系，包括组织、平台、工具、数据等等

我们可以将这四个特征作为判断是否属于数据中台的依据，下面就数据平台、数据仓库、数据工具链等概念做具体的比较。

1、数据平台与数据中台的区别

什么是平台？这里举个例子：

我们拿一个饮料厂的产品线来讲，他它可以生产果汁，还可以生产其他的产品，从原材料加工成饮料，它有很多环节，虽然品种不一样，但是它很多环节是类似的，比如装瓶、搅拌。

那么这几个不同的生产流程、生产线，我们可以把那些公共的部分合并起来，更加专业化，然后并且让他们独立去维护，之后把那些不同的产品面向客户，使客户体验不同的产品，使它独立出来，这就是平台化的思路。

所以，平台化的思路很重要的就是把那些有共性的资源，有共性的能力合并在一起，然后把那些面向客户的价值独立出来，这样的话，专业的人做专业的事情，并且对于企业的绩效也非常的有利，不揉在一块了，更加的清晰，这就是平台化的思路，可以看到，平台也是具有沉淀共享的性质的，因此很多人把平台当成中台来讲。

但平台每天想得是如何将业务系统中跟业务无关的技术剥离出来，然后制定这些技术的标准和规范，然后由自己来打造这些共性的底层的基础设施，然后鼓励大家统一接入，然后平台收收通道费就可以了。

同样的道理，数据平台强调的共性基础设施是数据，我把大家所需要的各种数据都采集好了，并且对所有人开放，大家按需取用就可以了，再也不用自己去汇聚各种数据了，当然我可能要收取一些使用费，比如数据交易中心就是一个典型的数据平台。

由此可见，数据平台不符合数据中台特征的（1）（3），即它跟业务是没有直接关系的，因为一旦有关系，意味着跨行业的规模化复制就存在问题，这是数据平台不想看到的。

你很容易发现，数据中台是限于行业或企业的，而数据平台则有更大的普适性，这是由数据中台的业务特性所决定的，如果一个企业跳出来对所有企业来说我有数据中台可以销售，显然是混淆了数据中台与数据平台的区别，但卖产品嘛，大家都懂的。

以hadoop为核心的大数据平台显然不能称其为数据中台，这很容易理解，如果一个企业把所有业务的数据都存储在Oracle里，我们能说这个Oracle数据库是数据中台吗？

数据湖可以认为是一种特殊的数据平台，其出发点是快速的探索数据从而创造价值，为了灵活性它抛弃了数据仓库的预先建模，暴露的就是直接的原始数据，因此不可能去沉淀什么共性能力，数据湖其实比一般的数据平台还差点中台的意思，不符合数据中台特征的（1）（2）（3），即跟业务无关，也不沉淀模型，更不可能开放复用。

2、数据仓库与数据中台的区别

数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持，一般有四个特征：

（1）面向主题：数据仓库都是基于某个明确主题，仅需要与该主题相关的数据，其他的无关细节数据将被排除掉

（2）集成的：从不同的数据源采集数据到同一个数据源，此过程会有一些ETL操作

（3）随时间变化：关键数据隐式或显式的基于时间变化

（4）数据仓库的数据是不可更新的：数据装入以后一般只进行查询操作，没有传统数据库的增删改操作。数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据，而不是联机处理的数据。

数据仓库一般是分层的，目的是为了解耦和共享，从而提升对应用的支撑效率，这其实非常符合中台的沉淀共性能力的理念：

（1） ODS（Operation Data Store），操作数据层，即原始数据层，又叫贴源层，与业务系统基本同构（可能会增加管理字段），目的是保留历史，解耦业务数据库，这样整个数据平台只需要访问一次业务数据库即可。所以ODS层存在的意义是尽可能减少对业务数据库的访问压力。ODS层有些时候会细分为两层，一个STG数据缓冲层，存原始数据，一个ODS，存简单清洗的数据。

（2）DWD（Data Warehouse Detail），明细数据层，对数据进行清洗、代码统一、字段统一、格式统一、简单聚合等工作。DWD层存在的意义是做数据的标准化，为后续的处理提供干净、统一、标准的数据。

（3）DWB（Data Warehouse Base），基础数据层，又叫轻度汇总层，遵照维度模型的原理，将数据拆成维度和事实，进行维度、事实的统一。对数据进行轻度汇总，形成指标结果。

（4）DWS（Data Warehouse Service），服务数据层，按照业务目标，对已经处理好的数据进行横向汇聚、纵向汇总。按照宽表模型进行数据冗余和预计算，以空间换时间。

数据仓库刚起步的时候，目的是融合整个企业的全部数据，打通数据之间的隔阂，消除数据标准和口径不一致问题，从而做好决策支持，表现形式一般是报表和指标，BI是其升级版本，从本质的角度来讲，数据仓库是面向业务主题的，其符合数据中台的标准（1），即为业务服务。

可惜的是，数据仓库恰恰也被困在了决策支持这个唯一的业务上，其对业务系统很少直接提供数据服务的支持，数据仓库对于业务的价值，大多需要通过管理者的决策体现出来，偶偶的侵入业务系统，也是做做亮点，比如搞个数据挖掘。

理论上，数据仓库跟数据中台很难说有本质区别，这是数据中台被数据仓库从业者诟病的原因，但两者对业务的支撑广度和深度不在一个级别上，数据仓库仅仅赋能决策支持，而数据中台对业务的支持是全方位的，其不仅通过API等形式直接嵌入到业务流程中发挥作用，而且还能通过数据产品直接创造价值。

事实上，由于数据仓库以前局限于决策支持这个业务，反倒限制了数据价值的发挥，管理者又对报表和指标这个业务特别敏感，因此元数据和数据质量管理成了数据仓库最核心的工作，而数据中台所倡导的模型开放、共享复用并不为老的数据仓库时代所重视。

现在很多人把汇聚全域数据作为数据中台与数据仓库的区别，显然没有抓住本质的东西，其实只有更多的前端业务需要数据仓库提供数据服务，才能驱动数据仓库去真正的汇聚全域数据，否则领导关注的KPI指标就那几个，汇聚全域数据对于这些KPI指标来说，其实没有那么高的价值。

量变导致质变，数据中台的提出有进步意义，它让我们基于业务的需要去打造数据仓库，而不是倒过来，即建了数据仓库然后再想着业务场景，数据中台与数据仓库的区别也不在于技术本身，而在于有没有业务思维。

由上可知，从技术角度上去否认数据中台意义不大，其实如果有了业务思维，不建数据仓库又如何？你提供一个位置API服务了很多前端应用，那这个API就可以称为微型的数据中台，从这个角度看，由于业务的牵引，数据中台又是超越数据仓库的。

因此，虽然数据仓库表面上符合数据中台特征的（1）（2）（3）（4），但如果你的企业建设数据仓库的业务思维没有转变，没有建立其之适配的业务运营体系，你建的数据仓库就不能称为数据中台。

实际上，业务思维的不同也影响到了数据仓库和数据中台技术实现的差异，以前的数据仓库虽然也在业务建模，但由于出口有限，因此打造API服务的必要性不是很大，因此，大多数据仓库其实都在做One-Data，One-ID的事情，但One-Service鲜有提及，阿里显然对于这个有更深入的认识，数据中台其实更应关注One-Service的实现和运营。

阿里提出数据中台这个概念的时候，很多数据仓库摇生一变都成为了数据中台，但这些数据仓库其实仍然是20年前的那个数据仓库。

3、数据工具链与数据中台的区别

很多厂家把数据开发、治理及运维工具当成了数据中台去售卖，显然混淆了数据中台这个概念，这跟大厂的宣传有点关系，比如很多大厂就把数据工具链、数据模型、数据服务合在一起当成数据中台，但这是不严谨的。

数据工具链只是高效实现数据中台的手段，但你不能把工具链当成数据中台本身，就好比业务中台包括很多收敛的微服务，但你不能把实现云原生的基础设施当成业务中台的本身，比如DevOps工具链。

为什么大厂要把数据工具链也画在数据中台架构图里呢？

因为数据模型和数据服务是比较薄的一层，没啥好说的，各行各业对于业务的抽象建模对于其它行业来讲缺乏借鉴意义，但实现这些数据模型和数据服务却需要强大的数据工具链支持，而数据工具链显然具有全行业的通用性，这是Show能力的卖点。

我们的确从大厂的数据工具链学到很多东西，但不能被工具迷糊了眼睛，把手段当成了目的，其实企业的软实力才是最重要的。

我们的目的永远是用数据直接服务业务，不管用什么手段，数据工具链显然不满足（1）（2）（3）（4），因此不能称是数据中台，也不建议纳入数据中台的范畴。

从以上的分析可知，数据仓库是跟数据中台最像的东西，奥妙就在于业务，不少文章也早就窥探到了其中的一些奥义，我这里也列一下，方便你比较。

比如《数据中台不是技术平台，没有标准架构》、《超越平台，数据中台的业务化、服务化及开放化！》、《你需要的不是中台，而是一名合格的架构师（附各大厂中台建设PPT）》、《中台的问题，是技术的问题，还是人的问题》、《没有中台的命，却得了中台的病》、《中台搞了2年，项目叫停，CIO被裁！本以为中台是道送分题，没想到是送命题！》、《什么是中台，什么不是中台？本质上所有的中台都是业务中台》等等。